Bridge Transfer

For a bridge transfer, the platform connects the caller to the called party in a full duplex conversation.

Figure 2-2 Audio Connections during a bridge transfer: <transfer bridge="true">

Any prompts preceding the <transfer>, as well as prompts within the <transfer>, are queued and played before the transfer attempt begins. The barge-in control applies normally. Specification of barge-in type is ignored; "hotword" is set by default.

The caller can cancel the transfer attempt before the outgoing call begins by barging in with a speech or DTMF command that matches an active grammar during the playback of any queued audio.

Listening for user input during a transfer

Platforms may optionally support listening for caller commands to terminate the transfer by specifying one or more grammars inside the <transfer> element. The <transfer> element is modal in that no grammar defined outside its scope is active. The platform will monitor during playing of prompts and during the entire length of the transfer connecting and talking phases:

• DTMF input from the caller matching an included DTMF grammar

• An utterance from the caller matching an included speech grammar

A successful match will terminate the transfer (the connection to the called party); document interpretation continues normally. An unsuccessful match is ignored. If no grammars are specified, the platform will not listen to input from the caller.

The platform does not monitor in-band signals or voice input from the called party.

Handling caller, called party, or network disconnections

While attempting to connect to the called party, the platform monitors call progress indicators (in-band and/or out-of-band, depending upon the particular connection type and protocols). For the duration of a successful transfer, the platform monitors for (out-of-band) telephony events, such as disconnect, on both call legs.

If the called party disconnects, the caller resumes his session with the interpreter. If the caller disconnects, the platform disconnects the called party, and documentinterpretation continues normally. If both the caller and called party are disconnected by the network, document interpretation continues normally.

The possible outcomes for a bridge transfer before and after the connection to the called party is established are described in the VXML specifications set out at this URL:

http://www.w3.org/TR/voicexml20/

If the caller disconnects by hanging up (either during a call transfer or call transfer attempt), the connection to the called party (if one exists) is dropped, a connection.disconnect.hangup event will be thrown, and dialog execution will transition to a handler for the hangup event (if one exists). The form item variable, and thus shadow variables, will not be set.

The following example attempts to perform a bridge transfer the caller to a another party, and wait for that conversation to terminate. Prompts may be included before or within the <transfer> element. This may be used to inform the caller of what is happening, with a notice such as "Please wait while we transfer your call." The <prompt> within the <block>, and the <prompt> within <transfer> are queued and played before actually performing the transfer. After the audio queue is flushed, the outgoing call is initiated. By default, the caller is connected to the outgoing telephony channel. The "transferaudio" attribute specifies an audio file to be played to the caller in place of audio from the far-end until the far-end answers. If the audio source is longer than the connect time, the audio will stop playing immediately upon far-end answer. See the next diagram.